TST: enable --fatal-meson-warnings for all tests #768
Conversation
dnicolodi
force-pushed
the
meson-fatal-warnings
branch
3 times, most recently
from
2725c98 to
0173a9c
Compare
mesonpy/__init__.py
Outdated
| objc = '{arch}-apple-{subsystem}-clang' | ||
| objcpp = '{arch}-apple-{subsystem}-clang++' | ||
| ar = '{arch}-apple-{subsystem}-ar' | ||
| strip = ['strip', '-arch', {arch!r}] |
There was a problem hiding this comment.
@freakboy3742 Can you please verify that this is correct? I have no experience with building for iOS. Thanks!
There was a problem hiding this comment.
This will be a valid invocation for strip; but I've never needed to call strip on any iOS program, so I'm not sure where I'd be looking to verify this works. Have you got an example in mind that would be using this?
There was a problem hiding this comment.
Thanks! Maybe calling strip in this way and checking that the resulting binary is still working would be a way to verify that this does something that at least is not harmful. The reason I'm adding this is that, without it, meson emits a warning https://github.com/mesonbuild/meson-python/actions/runs/15653996265/job/44102572727#step:10:1105
There was a problem hiding this comment.
Understood - I'll investigate and report back shortly (likely tomorrow my time, at this point)
There was a problem hiding this comment.
I think the correct way to get to the strip utility is to run something like xcrun --sdk iphoneos -f strip. The system strip may not work for iOS binaries.
There was a problem hiding this comment.
I think meson-python releases can happen more easily than CPython releases, thus applying fixes does not seem an issue, as long as we are informed of them. Another advantage is performance: not having the wrappers spares forking one extra sh processes which stays around for the duration of the execution (because the wrappers do not use exec) for each compilation command. Actually using xcrun to query the path to the compiler binaries two forks could be spared. Although, in practice this may be a pretty small performance penalty.
@rgommers What do yo think?
There was a problem hiding this comment.
It looks to me like the performance difference is going to be very small compared to the overall time it takes to build a wheel. So I'd go with the simplest solution, which is invoking the shims directly. Fixing a bug that may show up in a version of CPython that doesn't get bug fix releases anymore is years away, and if such a bug fix is needed, the unwrapping can then still be done.
There was a problem hiding this comment.
Yes, the performance considerations are moot. Still, a shim for strip does not yet exist and if we invoke xcrun directly for strip I don't see why we cannot do the same for all other compilation tools. I don't know what happens if meson-python writes a cross file that specifies a strip binary that does not exist.
There was a problem hiding this comment.
We can, the CPython shims just look a lot more complex.
Anyway, I am fine with that solution too if you prefer, any choice is valid here. Just my $2c that I'd make the minimal change only for strip here (maybe I'm just lazy:)).
There was a problem hiding this comment.
This strip wrapper change is now merged in gh-772. I'll leave this thread unresolved, since it's potentially interesting content also in the future.
|
There are still test failures. These are the tests where we set the RPATH via explicit linker arguments. We stop doing that in #724 thus I don't think it is necessary to find a way to allow these warnings to do not make the tests fail. |
dnicolodi
force-pushed
the
meson-fatal-warnings
branch
from
0173a9c to
d674d94
Compare
|
Enabling |
rgommers
added
the
maintenance
dnicolodi
force-pushed
the
meson-fatal-warnings
branch
8 times, most recently
from
d9ec656 to
5f18a56
Compare
Unless explicitly disabled in ``pyproject.toml``. This uses a pytest ``autouse`` fixture to monkeypatch the function that validates the ``pyproject.toml`` meson-python configuration to add ``--fatal-meson-warnings`` to the ``meson setup`` arguments, unless ``--no-fatal-meson-warnings`` is specified by the package.
This package tests adding RPATH entries via linker arguments. This functionality is deprecated in Meson but it is used in the wild thus we should make sure it keeps working.
dnicolodi
force-pushed
the
meson-fatal-warnings
branch
from
5f18a56 to
df35414
Compare
| meson_args: MesonArgs = collections.defaultdict(list) | ||
| for key, value in args.items(): | ||
| meson_args[key].extend(value) # type: ignore[index] | ||
| return meson_args |
There was a problem hiding this comment.
I'm not entirely happy with adding this function, but I didn't find a better way.
|
@rgommers I think we will keep testing adding RPATH entries with linker arguments, thus I added a way to disable fatal meson warnings for selected packages. This is ready for another review. |
4 participants
The test packages also work as examples. I think it is better to make sure that they are as correct as possible.